\section{Caching in the Distributed Environment}

Caching wird heute massiv und sinnvoll in der von Neumann 
Architektur eingesetzt. Im verteilten Systemen ist dies nicht der Fall.
Bei Datenbanksystemen bedeutet es jedoch, dass ein nicht vorhandener Cache jedes mal zu einem
Datenbankzugriff führt. Dies erzeugt Last auf der Datenbank sowie im Netzwerk.
Web basierte Anwendungen brechen oft zusammen da kein Cache genutzt wird.
Cache kann auch bei verteilen Systemen eingesetzt werden.
 
\subsection{Distributed Systems}



Verteilte Systeme bestehen aus verschiedenen Komponenten und sind verbunden mittels Netzwerken.
Kennzeichen eines verteilten Systems ist es, dass Aufgaben sinnvoll aufgeteilt werden. 
Auch hier können Caches verwendet werden, um häufig genutzte Daten schneller zugänglich zu machen.
Somit kann eine gesteigerte Performance und Verfügbarkeit der Applikation erreicht werden.

\subsection{Cache and the Principle of Locality}

Cache wird üblicherweise im Speicher angelegt um schnell abrufbar zu sein. Daten die oft angefragt werden
sollten also im Cache landen. Das wirft Fragen auf: Wie identifiziert man diese Daten und wie lange bleibt etwas
im Cache? Es gibt zwei Prinzipien von Caching: Temporal Cache und spatial Cache.

\subsection{Temporal Cache}

Dieses Prinzip eignet sich für häufig aufgerufene Daten. Ein Erstaufruf führt dazu dass der Datensatz im Cache landet.
Jeder weitere Aufruf auf diesen Datensatz wird mit dem Inhalt des Caches beantwortet. Dieses Verfahren 
führt zu einer Reduktion der Datenbanklast und steigert die Performace der Applikation. 
Gleichzeitig können auch Abhängige Datensätze gecached werden. Caching Regeln legen fest wie lange etwas im Cache
gehalten wird. Die meisten APIs enthalten Synchronisationsmethoden um den Cache aktuell zu halten.

\subsection{Spatial Cache} 

Das beste Beispiel für spatial cache sind Suchmaschinen. Wird ein Begriff gesucht werden nicht alle Datensätze 
geholt. Abhängig von der Ansicht werden nur die ersten drei Seiten aus der Datenbank geladen, angezeigt und gecached.
Es wird davon ausgegangen, dass der Benutzer meistens nicht mehr als die ersten drei Seiten ansieht. Auch hier
gibt es APIs die für Synchronisation zwischen Cache und DB sorgen. 

\subsection{Primed vs Demand Cache}

Primed (vorbereiteter) Cache bietet sich an bei statischen Ressourcen. Webbrowser nutzen dieses Verfahren um Seiten schneller
zu laden. Demand (nachgefragter) Cache hingegen wird verwendet bei nicht vorhersehbaren Daten.

\subsubsection{Primed Cache}

Primed Cache sorgt für eine Minimierung des Overheads um externe Ressourcen anzufragen. Er eignet sich dort
wo viele User Ressourcen lediglich anfragen, sprich read-only Szenarien. Primed Cache Server stehen zum Beispiel
zwischen verschiedenen Web Servern und Datenbanken, wobei die Web Server den Primed Cache beeinflussen können. Der Primed
Cache Server selbst kümmert sich um die Synchronisation der Daten.

\subsubsection{Demand Cache}

Demand Cache eignet sich wenn Ressourcen angefragt werden die nicht vorhergesehen werden können. Wird etwas angefragt
landet es danach im Cache zur Wiederverwendung. Hierbei müssen sich gecachte Daten lohnen in Hinsicht auf die Beschaffungskosten.

\subsection{Caching in the ORM World!}

 Object relational mapping (ORM) ist eine gute Brücke um OOP und RDBMS zu verbinden. Viele kommerzielle und auch opensource ORM Lösungen
 werden zu einem integralen Teil verteilter Systeme. Ein ORM Manager arbeitet mit einer Form von Objektgraphen, die sich anbieten für caching.
 So kann ähnlich wie bei der von Neumann Architektur auch bei der ORM Architektur caching angewandt werden.

\subsection{Transactional Cache}

Transaktion Objekte mit gültigem Status können im Transaction Cache gespeichert werden. Transaktionen sind wie folgt charakterisiert:
Atomar, konsistent, isoliert und langlebig. Ein Transaktion Objekt wird bearbeitet oder ein rollback wird durchgeführt. Bei einem rollback
werden alle involvierten Objekte in ihren Ursprungszustand versetzt. JBoss implementiert einen tranactional Cache.

\subsection{Shared Cache}

Es gibt zwei verschiedene Shared Caches. Der Prozess Cache steht allen gleichzeitig laufenden Threads eines Prozesses zur Verfügung. 
Clustered Cache hingegen wird von mehreren Prozessen eines oder mehrerer Rechner geteilt. Dies wird genutzt in verteilten Systemen.

\subsection{Chasing the Right Size Cache}

Für die Cachegröße gibt es keine Regel. Sie hängt von vielen Faktoren ab wie: verfügbarer Speicher, 32/64 Bit Single/Multicore Architektur, Hardware oder
Virtualisierung und weiteren. Das Patero Prinzip, eine Art Faustformel, besagt dass 80\% der Anfragen 20\% des Contents betreffen.

\subsection{Conclusion}

Ein geringer Einsatz von Caches kann einen großen Performace Zuwachs herbeiführen. Verschiedene caching Methoden können 
zusammen eine gute caching Plattform bilden. Kommende Technik wird die Zukunft der Cache Strategien verändern. Außerdem
spielt caching eine Schlüsselrolle beim Design verteilter Systeme und entscheidet darüber ob ein System großartig ist oder gut.

\subsection{Fazit}

Die Nutzung von Cache in verteilten Systemen erscheint mir mehr als sinnvoll. 
. Laut einem Bericht war Youtube
2007 allein für 10 Prozent des weltweiten Datenverkehrs im Internet 
verantwortlich \cite{youtube}. Dienste wie Youtube wären ohne gute Caching Taktiken
nicht denkbar. Der Artikel beschreibt gut verständlich wo und wie man Cache einsetzten kann und sollte.
Ich vermisse jedoch ein anschauliches Beispiel. Bestenfalls eines Dienstes der vorher ohne
Caching betrieben wurde und dann mit einer, im Artikel beschriebenen, Caching Strategie 
ausgerüstet wurde. Ein vorher nachher Vergleich wäre hier angebracht. 

